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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
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Foreword 

This Technical Specification (TS) has been produced by Joint Technical Conmiittee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Digital Video Broadcasting Project (DVB) is an industry-led consortium of broadcasters, manufacturers, network 
operators, software developers, regulatory bodies, content owners and others committed to designing global standards 
for the delivery of digital television and data services. DVB fosters market driven solutions that meet the needs and 
economic circumstances of broadcast industry stakeholders and consumers. DVB standards cover all aspects of digital 
television from transmission through interfacing, conditional access and interactivity for digital video, audio and data. 
The consortium came together in 1993 to provide global standardisation, interoperability and future proof 
specifications. 

The present document is part 1 of a multi-part deliverable covering IP Datacast: Implementation Guidelines for 
Mobility, as identified below: 

Part 1: "IP Datacast over DVB-H"; 

Part 2: "IP Datacast over DVB-SH". 



Introduction 



IP Datacast over DVB-H is an end-to-end broadcast system for delivery of any types of digital content and services 
using IP-based mechanisms. An inherent part of the IPDC system is that it consists of a unidirectional DVB broadcast 
path and a bi-directional mobile/cellular interactivity path. IPDC is thus a platform for convergence of services from 
mobile/cellular and broadcast/media domains. 



ETSI 



ETSI TS 102 611-1 VI .3.1 (2010-03) 



Scope 



The present document presents guidelines on how to develop terminals and network infrastructure equipment to allow 
seamless handover within the scope of one IP Platform, one ESG, and one IPDC Operator, in order to continue IP 
Datacast service consumption. Additionally, the present document specifies enablers for mobility between IP Platforms, 
ESGs, and IPDC Operators. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ISO/IEC 13818-1: "Information technology - Generic coding of moving pictures and associated 

audio information: Systems". 

[2] ETSI EN 302 304: "Digital Video Broadcasting (DVB); Transmission System for Handheld 

Terminals (DVB-H)". 

[3] ETSI TS 102 47 1 : "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic 

Service Guide (ESG)". 

[4] ETSI TS 102 470-1 : "Digital Video Broadcasting (DVB); IP Datacast: Program Specific 

Information (PSI)/Service Information (SI); Part 1: IP Datacast over DVB-H". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TS 102 474: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Service 

Purchase and Protection" . 

[i.2] ETSI TS 102 472: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content 

Delivery Protocols". 

[i.3] ETSI TR 102 377: "Digital Video Broadcasting (DVB); DVB-H Implementation Guidelines". 
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[i.4] ETSI TR 101 21 1: "Digital Video Broadcasting (DVB); Guidelines on implementation and usage 

of Service Information (SI)". 

[i.5] lEC 62002-1: "Mobile and portable DVB-T/H radio access - Part 1: Interface specification". 

[i.6] "Soft Handover in Terrestrial Broadcast Networks", Jani Vare, Matti Puputti, Proceedings of 

MDM2004. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

cell: geographical area that is covered with DVB-H signals delivering one or more particular transport streams 
throughout the area by means of one or more transmitters 

NOTE: The cell may in addition contain repeaters. Two neighbouring cells may be intersecting, or fully 

overlapping. The cell_id that is used to uniquely identify a cell is unique within each original_network_id. 
For hand-over purposes it is more convenient if the transport streams associated with the cell cover 
exactly the same area, or only one transport stream per cell is used. 

DVB Network: collection of MPEG-2 Transport Streams, each carried in a multiplex, and transmitted on a single 
delivery system 

NOTE: DVB Network is identified by network_id. 

home ESG: ESG(s) the terminal has been provisioned with by his Home IPDC Operator as its home configuration 

home IP Platform: IP Platform(s) the terminal has been provisioned with by his Home IPDC Operator as its home 
configuration 

home IPDC Operator: IPDC Operator that the terminal is registered to 

IP Flow: flow of IP datagrams each sharing the same IP source and destination address 

NOTE: An IP Flow is identified within an IP Platform by its source and destination addresses. IP Flows on 
different IP Platforms may have the same source/destination addresses, but are considered different 
IP Flows. IP Flows may be delivered over one or more IP Streams. 

IP Platform: set of IP Flows managed by an organization 

NOTE: The IP Platform represents a harmonized IP address space that has no address collisions. An IP Platform 
may span several Transport Streams within one or more DVB Networks. Several IP Platforms may 
co-exist in the same Transport Stream. IP Platform is identified by platform_id. 

IP Stream: physical mapping of an IP Flow to transport_stream_id, original_network_id, service_id, component_tag, 
and IP source/destination addresses 

NOTE: An IP Stream is delivered on an MPE section stream. 

IPDC Handover: change of the terminal connection (one or more of the parameters original_network_id, 
transport_stream_id, network_id, cell_id / subcell_id) within the scope of one IPDC Operator (while accessing IPDC 
services) 

IPDC Operator: characterized uniquely by IPDCOperatorld and IPDCKMSId 

NOTE: A physical IPDC Operator may have several IPDCOperatorlds which each map to an IPDC Operator in 
the defined sense. 

IPDC Roaming: change of a terminal connection from an IPDC Operator to a Roaming IPDC Operator 

local IPDC Operator: IPDC Operator that himself offers services on a certain IP Platform and ESG 
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multiplex: stream of all the digital data carrying one or more services within a single physical channel (characterized 
by parameters like carrier frequency and modulation modes) 

Service Mapping: procedure based on the ServiceMapping element in the ESG Service fragment, allowing the terminal 
to find the same or similar IPDC service when it changes the reception, and to continue consuming it 

Sub-Cell: geographical area that is part of the cell's coverage area and that is covered with DVB-H signals by means of 
a transposer 

NOTE: In conjunction with the cell_id the cell_id_extension is used to uniquely identify a subcell. 

Transport Stream (TS): stream of transport_packets, as defined in ISO/IEC 13818-1 [1] 

roaming configuration: combination of platform_id, ESG_URI (provider_URI and providerlD in case of IPDC 
phase I), and the pair of IPDCOperatorld and IPDCKMSId 

roaming IPDC Operator: IPDC Operator that the terminal is not registered to, but that has a roaming contract with the 
Home IPDC Operator 

unknown IPDC Operator: IPDC Operator for which a terminal is lacking information to identify whether an IPDC 
roaming contract with the Home IPDC Operator exists 

visited ESG: ESG which is not a Home ESG 

NOTE: The Home IPDC Operator may be a Local IPDC Operator on this ESG or not. 
visited IP Platform: IP Platform which is not a Home IP Platform 

NOTE: The Home IPDC Operator may be a Local IPDC Operator on this IP Platform or not. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

BAT Bouquet Association Table 

BER Bit Error Rate 

CA Conditional Access 

CTA Clear-To-Air 

DM Device Management 

DP Derived Power 

DVB Digital Video Broadcasting 

DVB-H DVB-Handheld 

NOTE: See EN 302 304 [2]. 

ESG Electronic Service Guide 

NOTE: SeeTS 102 471 [3]. 

FDT File Delivery Table 

FLUTE File deLivery over Unidirectional Transport 

ID Identifier 

INT IP/MAC Notification Table 

IP Internet Protocol 

IPDC IP DataCast 

KMS Key Management System 

MAC Media Access Control 

MFER MPE-FEC Frame Error Rate 

MO Management Object 

MPEG Moving Picture Experts Group 

NIT Network Information Table 

OMA Open Mobile Alliance 

OSF Open Security Framework 

PAT/PMT Program Association Table/ Program Map Table 
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PER 

PFP 

PID 

PSI 

QEF 

QoS 

RSSI 

SFP 

SI 

SNR 

SPP 

TPS 

TS 

URI 



Packet Error Ratio 

Picture Failure Point 

Packet Identifier 

Program Specific Information 

Quasi Error Free 

Quality of Service 

Received Signal Strength Indicator 

Subjective Failure Point 

Service Information 

Signal to Noise Ratio 

Service Purchase and Protection 

Transmission Parameter Signalling 

Transport Stream 

Uniform Resource Identifier 



Background 



The focus of the present clause is to provide a brief introduction on PSI/SI tables and descriptors used in IPDC in 
DVB-H Systems as well as to describe basic mobility concepts. 



4.1 



Overview 



A DVB Network is uniquely identified by a network_id. A DVB Network consists of one or more Transport Streams 
(TSs), each being transmitted by one or more DVB signals. All emitting sites identified by cell_ids of a DVB Network 
do not need to transmit all TSs of the network. Information about a DVB Network is available within the NIT sub_table 
(identified by network_id). The NIT lists all TSs and DVB signals available within the DVB Network. The NIT is 
carried within each DVB Network. 



DVB networks 


DVB network 1 

ID: network id 

PSI/SI: NIT 






^^ 








^^ 










^^--^ 


Transport Streams 


Multiplex 1 

ID: transport_stream_id + 

original network id 

PSI/SI: PAT 




Multiplex 2 

ID: transport_stream_id + 

original network id 

PSI/SI: PAT 




Multiplex 3 

ID: transport_stream_id + 

original network id 

PSI/SI: PAT 








^^ 










^^ 


^ 






"" 


^^--^ 


DVB services 


DVB service 1 
ID: service id 
PSI/SI: PMT 




DVB service 2 
ID: service id 
PSI/SI: PMT 




DVB service 3 
ID: service id 
PSI/SI: PMT 








^^ 










^^ 


^ 






"■ 


\^ 


Elementary Streams 


Component 1 
ID: component_tag, PID 




Component 2 
ID: component_tag, PID 




Component 3 
ID: component_tag, PID 



Figure 1 : Hierarchy of data streams in DVB-H (1) 

An IP Stream is a single data stream delivering an IP Flow. An IP Flow is a flow of IP datagrams, each sharing the 
same IP source and destination addresses that represent the data content of a stream. An IP Stream represents an 
instantiation of such an IP Flow to transport_stream_id, original_network_id, network_id, service_id, component_tag, 
and IP_source / destination addresses. An IP Flow belongs to exactly one IP Platform. Note that an IP Stream may be 
announced by multiple INT sub_tables, possibly making it part of multiple IP Platforms. 
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IP platforms 


IP platform 1 

ID: platform id 

PSI/SI: INT 






^^ 


"^^-^ 
















^^-^ 


IP flow 


IP flow 1 
ID: IP address 




IP flow 2 
ID: IP address 




IP flow 3 
ID: IP address 








^^ 


"^^^\ 


















^^--^ 


IP streams 


IP stream 1 

ID: transport_stream_id + 

original network id + 

PID 




IP stream 2 

ID: transport_stream_id + 

original network id + 

PID 




IP stream 3 

ID: transport_stream_id + 

original network id + 

PID 



Figure 2: Hierarchy of data streams in DVB-H (2) 



4.2 networkjd and original_network_id 

In DVB, the original_network_id is defined as the network_id of the network where the TS originated. For terrestrial 
DVB the concept of an original network, with an original_network_id, could be interpreted as a sort of abstract 
hypothetical network feeding all real networks (in the sense of network_id) in e.g. a country. The original_network_ids 
are typically allocated by DVB on a per-country basis. For each country, a range of network_ids is allocated by DVB, 
which are all different from the original_network_id. It may happen that the original_network_id is the same as the 
network_id of the actual network. 



4.3 transport_stream_id 



From the point of view of the DVB -SI specification a DVB Network is simply a "collection of MPEG-2 Transport 
Stream (TS) multiplexes transmitted on a single delivery system", with no mentioning of requirements for emission in 
all cells of the network. From the point of view of [4] there are therefore no particular rules whether a TS needs to be 
broadcast in all cells of a network. It is perfectly in line with [4] to have e.g. a nationwide network with a number of 
regional TSs, each with unique transport_stream_id and content. 



4.4 platformjd 



The IP Platform represents a harmonized IP address space that has no address collisions. An IP Platform is identified by 
the platform_id. 



4.5 



ESG URI 



An ESG is a special service describing IPDC Services available on an IP Platform. Several ESGs may co-exist on the 
same IP Platform. An ESG is uniquely identified by ESG_URI if the ESG is based on [3] VI. 3.1 or later and by 
providerURI and providerld if the ESG is based on [3] VI. 1.1 or VI. 2.1. 

4.6 IPDCOperatorld and IPDCKMSId 

An IPDC Operator is an entity managing key streams. The IPDCOperatorld together with the IPDCKMSId 
(a.k.a. CA_system_ID) is used to identify the IPDC Operator. 
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The IPDCOperatorld is used in other IPDC specifications especially in the SPP context [i.l]. An integer value has been 
used for the IPDCOperatorld within the OSF SPP profile. The ISCrypt specification makes use of a string value (or 
anyURI) for this purpose. The string type is used for IPDCOperatorld also in TS 102 471 [3] and TS 102 472 [i.2]. The 
DVB Project maintains a central register for the IPDCOperatorlds related to standardized KMS. This open registration 
data base allows the provisioning of terminals with IPDCOperatorlds and facilitate the process of service discovery for 
terminals when roaming .The registry contains for roaming signalling purposes both a 16-bit unsigned integer and a 
string value (or anyURI) of the IPDCOperatorld. 

The value 0x0000 for the IPDCKMSId is reserved for non-encrypted services. 



4.7 Rules of uniqueness 



The cell_id that is used to uniquely identify a cell shall be unique within each original_network_id [4] . This implies that 
two networks (network_ids) within one original_network_id (one country) cannot use the same cell_ids for different 
cells. 

A TS can be uniquely referenced through the path original_network_id/transport_stream_id [4]. In other words, a 
transport stream is unique in the scope of an original_network_id. 

For each country a range of network_ids are allocated by DVB, therefore the network_id is unique in the scope of the 
original_net work_id . 

An IP Platform may span several Transport Streams within one or more DVB Networks. On the other hand, several IP 
Platforms may co-exist in the same Transport Stream. An IP Platform can be uniquely referenced with platform_id, or 
the set of both platform_id and network_id in the case the platform_id is in the non-unique range. Global platform_ids 
are registered by DVB. Therefore, an IP Platform is or can be made globally unique. 

Several ESGs may co-exist on the same IP Platform. ESG_URI and providerURI are globally unique. 

The IPDCOperatorld is unique for each KMS, identified by the IPDCKMSId (mapped on a CA_System_ID). The 
IPDCOperatorld is assigned by the DVB Office in the case where the IPDCKMSId (or CA_System_ID) is in the range 
of the standardized KMS systems (values 0x0001 to OxOOFF) to ensure uniqueness of IPDCOperatorld within 
standardized IPDCKMSId. One or more IPDCOperatorlds can be referenced in any ESG. 

4.8 Mobility concepts 
4.8.1 Basic handover concept 

The basic mechanism for services access and handover within IPDC over DVB-H is to use the IP address (and the IP 
Platform) for the service, as provided by the ESG, and then via the INT find the global path(s) for the IP address: 
{original_network_id, network_id, transport_stream_id, service_id, component_tag} where the IP Stream of the service 
can be found. The NIT, together with cell_id on TPS bits, will provide the link between this global path and 
frequency/cell_id/location of a particular TS. 

There are several reasons why a simplified handover approach, relying e.g. on transport_stream_id and/or service_id 
would not in general work. 

Considering the variety in interpretations regarding the use and exact meaning of TS/transport_stream_id, one cannot 
e.g. be sure to find the desired IP Flow(s) even if the transport_stream_id is the same. The receiver cannot rely only on 
the combination {original_network_id / service_id}. 

In the case the triplet {original_network_id / transport_stream_id / service_id} is identical, handover between 
network_ids would be possible. 

In general, a service_id may contain several component_tags, with one elementary stream on each. Knowing just the 
service_id is not sufficient to find the IP Flow. 

The service_id may even be different if the transport_stream_id is different. Finally, some interpretations may use the 
service_id, not to announce a particular IP Flow (or set of IP Flows), but as a label for "IPDC services", without any 
guarantee regarding the actual IP Flow(s) being carried within the service_id. 
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As a matter of fact, the basic mechanism for bootstrapping, service access and handover is very robust against various 
interpretations of terminology and PSI/SI rules. If a receiver uses the basic mechanism and gets: 

the IP address (and IP Platform) of the desired IP Flow from the ESG; 

the global path(s), i.e. {original_network_id, network_id, transport_stream_id, service_id, component_tag} of 
the IP address from the INT; 

the cell_id/frequency/location of the desired transport_stream_id from the NIT (NIT actual and NIT other); 

the celljd via TPS bits; 

the PID of the desired elementary stream, carrying the IP Stream, from the PAT/PMT on the target TS; 

then service access and handover will work in any case. 

Details on the TPS data used required for handover support with IP Datacast may be found in TS 102 470-1 [4] and 
TR 102 377 [i.3], clause 8.5. 

Details on avoiding data loss when performing handovers may be found in TR 102 377 [i.3], clause 8.5. 

4.8.2 Basic concept for roaming and special mobility cases 

The basic idea is to use a parameter set ("roaming configuration") consisting of the three parameters platform_id, 
ESG_URI, and the pair of IPDCOperatorld and IPDCKMSId, in order to identify mobility cases beyond handover. 
These other cases comprise roaming as well as special mobility cases, which are neither roaming nor handovers. 

The platform_id and the network_id are signalled within the PSI/SI tables. They are thus easily and quickly accessible. 

The ESG_URI, provider_URI and providerlD are signalled in the ESG bootstrap. 

The IPDCOperatorld and IPDCKMSId are also signalled in the ESG bootstrap for roaming purposes in order to enable 
quick roaming partner discovery. A specification of this signalling (Roaminglnformation Descriptor) is provided in 
annex A. 



5 Use cases 

5.1 Handover use cases 

5.1 .1 Overview of handover use cases 

In this clause, different handover use cases are listed which may occur due to terminal mobility in an IP Datacast over 
DVB-H broadcast system. The handover use cases are distinguished based on usage of PSI/SI tables and TPS. Each 
handover use case requires the terminal to apply a strategy to maintain, whenever possible, service continuity (i.e. no 
user perceivable interruption of the IPDC service being consumed). 

Table 1 summarizes the mobility use-cases for a terminal acquiring IP Flows from a given IP Platform. 
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Table 1 : Handover use cases 



Case 


original_n 

etworkjd 

change 


transport_stre 
amjd change 


networkjd 
change 


celljd / 

subcelljd 

change 


Handover based on 
TPS and NIT 
(see note 1) 


Handover based on 

INT, TPS and NIT 

(see note 1) 


1 








X 


applicable 


Applicable 
(see note 2) 


2 






X 


X 


applicable under 
condition (!) 


applicable under 
conditions (!) 
(see note 3) 


3 




X 




X 


not applicable 


applicable 


4 




X 


X 


X 


not applicable 


applicable under 
conditions (!) 
(see note 3) 


5 


X 


X 


X 


X 


not applicable 


applicable under 
conditions (!) 
(see note 3) 


NOTE 1 : See clause 6.2 and DVB-H IG TR 1 02 377 [i.3]. 

NOTE 2: INT not necessary. 

NOTE 3: This is possible since the INT shall announce IP Flows also on other networks. 


Condition (1): Target NIT is available (by NIT_Other or other means). 



Figure 3 graphically highlights the use-cases of table 1 . 




Figure 3: Handover use cases 1 to 5 

5.1 .2 Detection of alternative service reception parameters 
5.1 .2.1 Handover Use Case 1 : Change of celljd or subcelljd 

In this scenario, the alternative services reception parameters could be found in the NIT (actual) as follows: 

i) The terminal checks the other_frequency_flag in the terrestrial_delivery_system_descriptor in the NIT of the 
actual network to determine whether other frequencies are in use. In this scenario, this flag will show as true. 

ii) The terminal could acquire information on all other frequencies and their cell (sub cell) ids by decoding the 
cell_frequency_link_descriptor. 

iii) The terminal could acquire information on the geographical location of such cells and the geographical 
location of the current cell by decoding the cell_list_descriptor. 
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Based on this, the terminal could check the availability of the signals of the cells where the terminal is located and 
select the ones with the best quality as candidates to handover to. 
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A 
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■H±> 



^ 



cell id: 2 



5.1.2.2 



Figure 4: Handover scenario 1 



Handover Use Case 2: Change of celljd and networkjd 



In this scenario, the terminal can determine other networks in which the same TS and therefore the same IP Flow, is 
available. 

If two TSs have the same TS_id and original_network_id, it means they are identical. The terminal needs to find the TS 
that has the same TS_id and original_network_id from the NIT(other), and the corresponding reception parameters from 
the NIT(other): 

i) The terminal could find the TS that has the same TS_id and original_network_id from the NIT(other). 

ii) The terminal could acquire information on all the frequencies and their cell_ids for this TS from the 
cell_frequency_link_descriptor in NIT(other). 

iii) The terminal could acquire information on the geographical location of such cells and the geographical 
location of the current cell by decoding the cell_list_descriptor from NIT(other). 

Based on this, the terminal could check the frequencies carrying the same TS in the neighbouring cells belonging to 
another network and select the one with the best quality. 
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Figure 5: Handover scenario 2 
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Figure 6: PSI/SI support for handover scenario 2 
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5.1 .2.3 Handover Use Case 3: Change of celljd and transport_streann_id 

In this scenario, the terminal could find the same IP Flow in another TS from the INT sub-table (i.e. as part of the same 
IP Platform), and corresponding reception parameters in NIT(actual): 

i) The terminal could find out each TS that carries the same IP Flow by decoding the IP/MAC 
stream_location_descriptor in the INT sub-table. 

ii) The terminal could acquire information on all the frequencies and their cell_ids for these TSs by decoding the 
cell_frequency_link_descriptor in NIT(actual). 

iii) The terminal could acquire information on the geographical location of such cells and the geographical 
location of the current cell by decoding the cell_list_descriptor from the NIT(actual). 

Based on this, the terminal could check the availability of the signals of the cells accessible where the terminal is 
located and select the ones with the best quality as candidates to handover to. 
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Figure 7: Handover scenario 3 
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Figure 8: PSI/SI support for handover scenario 3 

5.1 .2.4 Handover Use Case 4: Change of celljd and networkjd and 

transport_streann_id 

In this scenario, the terminal can determine other networks in which other TSs carrying the same IP Flow are available. 

The terminal could find out that the same IP Flow is available on another TS from the INT sub-table. From NIT(other), 
the terminal can get information on other networks carrying other TSs with the same IP Flow: 

i) The terminal could find each TS that carries the same IP Flow from the IP/MAC streamJocation_descriptor in 
the INT sub-table. 

ii) The terminal could acquire information on all the frequencies and their cell Jds for these TSs from the 
cell_frequencyJink_descriptor in NIT(other). 

iii) The terminal could acquire information on the geographical location of such cells and the geographical 
location of the current cell by decoding the cellJist_descriptor in NIT(other). 

Based on this, the terminal could check the frequencies carrying the same TS in the neighbouring cells belonging to 
another network and select the one with the best quality. 
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Figure 9: Handover scenario 4 
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Figure 10: PSI/SI support for handover scenario 4 
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5.1 .2.5 Handover Use Case 5: Change of Original Network 

The terminal could find the same IP Flow in another TS from the INT sub-table that also carries information for other 
networks where the same IP Platform is available. Corresponding reception parameters are to be found in the 
NIT(other): 

i) The terminal could find each TS that carries the same IP Flow from the IP/MAC stream_location_descriptor in 
the INT. 

ii) The terminal could acquire information on all the frequencies and their cell_ids for these TSs from the 
cell_frequency_link_descriptor in NIT(other). 

iii) The terminal could acquire information on the geographical location of such cells and the geographical 
location of the current cell by decoding the cell_list_descriptor in NIT(other). 

Based on this, the terminal could check the frequencies carrying the same TS in the neighbouring cells belonging to 
another network and select the one with the best quality. 
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Figure 1 1 : Handover scenario 5 
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Figure 12: PSI/SI support for handover scenario 5 

5.2 Roaming and special mobility use cases 
5.2.1 Overview of Roaming and special mobility use cases 

There are 7 use cases out of which 5 are described in in table 2 and clause 5.2.2, the two remaining are not considered 
valid. 
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Table 2: Roaming and special mobility use cases 



Case 


Change of 


Comment 


Physical 
Delivery 
Platform 


ESG 


IPDC Operator 


platformjd 
(if not unique, 

also 
networkjd) 


providerURI and 

providerlD (IPDC 

phase 1) 

ESG URI 

(IPDC phase 2) 


IPDCOperatorl 

d and/or 

IPDCKMSId 


1 






X 




2 




X 


X 




3 


X 


X 


X 




4 




X 






5 


X 


X 






6 


X 






ESG supposed to change with change of IP 
Platform. Should be treated by the terminal as 
use case 5. 


7 


X 




X 


ESG supposed to change with change of IP 
Platform. Should be treated by the terminal as 
use case 3. 
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Case 5 



Figure 13: Roaming and special mobility use cases 

5.2.2 Description of use cases 



5.2.2.1 



Roaming Use Case 1 



Roaming use case 1 is shown in figure 14. The terminal changes the service reception from IPDC Operator 1 to IPDC 
Operator 2 in the same ESG and IP Platform. 
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Figure 14: Roaming use case 1 

Characteristics of this use case: 

• There are two different IPDC Operators in the same ESG and IP Platform. 

• Some services may be owned by both IPDC Operators, while others may belong to one IPDC Operator only. 

5.2.2.2 Roaming Use Case 2 

Roaming use case 2 is shown in figure 15. The terminal changes the service reception from the IPDC Operator 1 in 
ESG 1 to IPDC Operator 2 in ESG 2, but still on the same IP Platform. 
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Figure 15: Roaming use case 2 

Characteristics of this use case: 

• Different IPDC Operators in different ESGs use the same IP Platform. 

• The ESGs may contain common services, while others may differ. 

5.2.2.3 Roaming Use Case 3 

Roaming use case 3 is shown in figure 16. The terminal changes the service reception from IPDC Operator 1 in ESG 1 
on the IP Platform 1 to IPDC Operator 2 in ESG 2 on the IP Platform 2. 
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Figure 16: Roaming use case 3 

Characteristics of this use case: 

• Each IPDC Operator uses a dedicated ESG and IP Platform. 

• The ESGs may contain common services, while others may differ. 

5.2.2.4 Special Mobility Use Case 4 

special mobility use case 2 is shown in figure 17. The terminal changes the service reception from ESG 1 to ESG 2 on 
one IP Platform and on one IPDC Operator. 
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Figure 17: Special mobility use case 4 
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Characteristics of this use case: 

• On one IP Platform, two different ESGs describe IPDC services of the IPDC Operator. 

• The ESGs may contain common services, while others may differ. 



5.2.2.5 



Special Mobility Use Case 5 



special mobility use case 5 is shown in figure 18. The terminal changes the service reception from ESG 1 in IP 
Platform 1 to ESG 2 in the IP Platform 2, but still on the same IPDC Operator. 
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Figure 18: Special mobility use case 5 
Characteristics of this use case: 

• One IPDC Operator uses two different ESGs on two IP Platforms. 

• The ESGs may contain common services, while others may differ. 



6 Terminal behaviour 

6.1 General mobility procedure 

In the case the reception quality of the currently consumed DVB-H signal decreases, a terminal should try to continue 
service reception by performing a handover to an alternative signal. However, a handover with service continuation is 
only possible in the case that an alternative signal exists where the Home IPDC Operator, the Home ESG and Home IP 
Platform are present on an alternative. The implementation guidelines for handovers are given in clause 6.2. 

In the case that the Home IP Platform is still present but either the Home ESG or Home IPDC Operator are not, the 
terminal can still try to perform service continuation. In the case that the handover fails or the Home IP Platform is not 
present, service continuation will typically not be possible. The terminal should in that case try to access other services 
on the alternative signal. The implementation guidelines for these roaming and special mobility cases are given in 
clause 6.3. 

6.2 Handover implementation guidelines 
6.2.1 General procedure 

A handover consists of several high-level steps which are listed below. 
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Figure 19: High-level handover procedure 



1) Initialization: 

Within the initialization phase, the terminal has to acquire a "start frequency" used for DVB-H reception. 
This frequency may, for example, be acquired by a signal scan or by provisioning the terminal 
accordingly. 

At least the ESG and possibly additional services have to be received, otherwise the execution of a 
handover does not make sense. 

2) Determine list of candidate signals: 

Within this phase, the terminal has to acquire parameters of possible alternative signals by making use of 
information in the PSI/SI tables. Specifically, the NIT and INT tables have to be analyzed. 

The terminal generates a list of a number of candidate signals suitable for a handover. 

3) Determine possible handover cases: 

Within this phase, the handover case(s) of the candidate signal(s) is (are) determined. 
Monitor handover conditions: 



4) 



5) 



The terminal monitors the signal quality (e.g. signal strength, SNR, error rates, etc.) of the current signal 
and candidate signals. 

The terminal generates a list of candidate signals (best to worse) in order to select the best handover 
candidate. 

Execute handover: 

Finally, the handover may be executed. 

Afterwards, the terminal continues with step 2. 



6.2.2 Initialization 

In order to obtain a start frequency, a signal scan may be used, or alternatively, the terminal may be provisioned with a 
certain start frequency. 

The signal scan is a process which can be said to provide the foundation for the service discovery and handover. The 
run of the signal scan is implementation specific. However, due to the fact that NIT other is not mandatory for the 
network, a receiver might want to run the signal scan occasionally in order to be up to date with the new networks 
which might become available, especially if the receiver is moving long distances. 
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In the signal scan, the receiver scans signals within the selected frequency range, which may be exhaustive or include 
only a subset of the all possible frequencies. The used frequency offset may also cover all possible bandwidth 
possibilities or it may be determined based on the information of the current location, if available. The steps involved in 
the general signal scan dataflow are described below: 

• Step 1 : The receiver attempts to synchronize to the signal within the given frequency range. 

• Step 2: Prior to the synchronization to the signal completely, receiver may have TPS lock. 

• Step 3: In the case TPS lock is achieved, it is inspected whether the DVB-H indicator within TPS bits indicates 
that the signal carries DVB-H services. If the signal is a DVB-H signal, the receiver attempts to synchronize to 
the signal. Otherwise the procedure continues to step 5. 

• Step 4: In case the synchronization is successful, receiver starts to seek and receive the PSI/SI. 

• Step 5: In case there are no more signals to scan, the procedure is exited. Otherwise the scan is continued from 
the next possible frequency. The list of possible frequencies, which are to be scanned, may be limited based on 
information carried within NIT. 

6.2.3 Determine list of candidate signals 

As the next step to prepare a handover, the terminal generates a list of neighbouring cells. By using information from 
the SI, it is possible to extract information on the location of the current cell and also of other cells. The necessary 
process for this is discussed in detail in TR 101 21 1 [i.4] and is similar to DVB-T handovers. 

6.2.4 Determine handover case 

On the basis of information in the INT, the terminal is able to find parameters of alternative signals ("handover 
candidates") from adjacent cells that also carry the currently consumed IP Flow(s). For each of these handover 
candidates, the terminal needs to evaluate the handover case to access the new signal. Figure 20 shows how to 
determine the handover case that is valid for a certain handover candidate. The handover cases are discussed in detail in 
clause 5.1 of the present document. Based on the information in clause 5.1, a handover algorithm suitable for the 
present handover case may be chosen. The algorithms themselves are described in clause 6.2.5. 
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Figure 20: Decision on handover case 
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6.2.5 Monitor handover conditions 

A handover may be advantageous if the reception conditions are (or may be assumed to be) better when the terminal 
would change reception to an alternative signal that also carries the IP Flow(s) currently being received. The exact 
criteria used for this purpose are up to implementation and no binding algorithms have been specified. 

There are a number of parameters which may be used in the decision process. A number of these parameters are 
outlined in detail below. 

In order to avoid ping-pong effects (meaning the terminal changing between two signals unnecessarily frequently), a 
hysteresis should be used for any criteria. 

There are two separate procedures that must be done during the monitoring phase. 

First, the existing signal quality must be monitored in order to evaluate the quality of the signal on which the current IP 
Flow(s) is being consumed. If the current signal-quality is "good enough", handover will not be necessary. 

Second, any viable alternative signals must be evaluated, so that if handover is to take place the "best" alternative signal 
available will be selected. 

If there is not a "better" alternative signal available, then regardless of the condition of the current signal, handover 
should not be attempted. 

6.2.5.1 Parameters that may be used in monitoring and evaluating 

For DVB-H receivers, there are many parameters that may be monitored and subsequently used in determining (a) when 
handover should take place and (b) the best alternative signal to handover to. 

These parameters include, but are not limited to, the following: 

1) RSSI (Received Signal Strength Indicator): 

The RSSI gives the full spectrum power available at the antenna, over an entire spectrum range. 

RSSI is a measurement of the received radio signal strength (an energy measurement, not necessarily a 
quality measurement). 

2) DP (Derived Power): 

When the signal is processed by the receiver, there will be signal-conditioning performed on that signal. 
In this signal-conditioning stage, there will be a number of filtering and gain stages applied. 

As a result of applying some or all of these stages, it will be possible to derive a power level for the 
received "wanted signal". 

This derived power level may be known as the Derived Power, and it is a good early indicator of the 
possible quality-of- signal available. 

This indicator does not distinguish between the signal power and the noise power. 

3) SNR (Signal to Noise Ratio): 

The SNR is the ratio of the (wanted) signal power to the noise power that is corrupting it: it compares the 
power level of the desired signal to the power level of noise. 

This indicator will be available after the signal conditioning has completed in the signal-conditioning 
stage. 

This value is a good early indicator of the quality-of-signal available. 

4) BER (Bit Error Rate): 

The Reference BER is defined as: BER = 2 x 10"^ after Viterbi decoding in the receiver. 

This criterion corresponds to the DVB-T standard defined Quasi Error Free (QEF) criteria, causing "less 
than one uncorrected error event per hour" [i.5]. 
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It should be noted that the Reference BER is considered to be an un- suitable criterion in the mobile 
environment due to fast channel variations. 

In mobile cases, the Reference BER criteria may give unstable values which could result in an 
underestimation of DVB -H capabilities. 



5) Packet Error Ratio (PER) : 

The PER is measured as the number of non-correctable RS packets that were received, over the total 
number of RS packets received. The rule-of-thumb subjective-failure value, as defined in [i.5], is 
considered to be 1 x 10""^: 

a) Picture Failure Point (PEP). 

The picture failure point is defined in [i.5] as the minimum C/N value for more than 1 TS-packet 
error in 10 seconds. 

b) Subjective Eailure Point (SEP) in mobile reception. 

The SEP is defined in [i.5] as a Packet Error Rate (PER) of 1 x lO""^ after the RS-decoder at the 
demodulator TS-output. 

The SEP corresponds to: "On average, one visible error in the video, during an observation period 
of 20 seconds". 

The observation period [i.5] for the PER-measurement should be at least 800 000 TS-packets 
(corresponding to roughly 2 min with 16QAM CR=l/2 GI=l/4 mode). 

6) MEER (MPE-EEC Erame Error Rate) : 

The MEER criterion detects errors after complete demodulation and decoding: i.e. after the Viterbi, 
Reed-Solomon and MPE-EEC steps have been completed. 

MEER is the ratio of the number of non-correctable frames over the number of received frames [i.5]. A 
minimum of 100 received frames is recommended. A very small change in C/N will result in a large 
change in MEER. 

A threshold value known as MEER5 is considered to be the "limit of an acceptable quality of 

image" [i.5]. MEER5 means that 5 % of the total number of received frames had non-correctable errors. 

If a DVB-H signal has degraded to an MEER5 level, then the quality of the service being offered has 
already degraded too much. When detecting signal-degradation, MEERl would be a better threshold 
value to use. 

Eor a typical DVB-H receiver, a pictorial overview of where each of these measurements can be taken is shown in 
figure 21. 
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Figure 21 : Parameters for handover decision 

Each of these parameters has advantages and disadvantages associated with it, and some are more suitable for use than 
others. 
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Table 3: Possible parameters for handover decision making 



Parameter 


Advantages 


Disadvantages 


RSSI 


Can be measured quickly. 

Gives a good early indication of poor 

reception conditions. 

No need to demodulate a transport 

stream to estimate RSSI. 


Supplies an estimate for the energy 

available in the band, not the quality of the 

signal. 

Does not give any indication of bit- or 

byte-errors, and so does not provide 

deterministic QoS metrics. 


DP 


Can be measured quickly. 

Gives a good early indication of poor 

reception conditions. 

No need to demodulate a transport 

stream to estimate DP. 


May not be available on some 

implementations. 

Supplies an estimate of the "wanted" 

energy received: but this estimate does 

not distinguish between the signal power 

and the noise power. 

Does not give any indication of bit- or 

byte-errors, and so does not provide 

deterministic QoS metrics. 


SNR 


Can be measured quickly. 

Gives a good early indication of 

reception conditions. 

Gives a relative signal quality. 

No need to demodulate a transport 

stream to estimate SNR. 


Does not give any indication of bit- or 
byte-errors, and so does not provide 
deterministic QoS metrics. 


BER 


Gives a good indication of current 
signal quality. 


Needs to demodulate a transport-stream. 
Not reliable in once-off measurements. 
Can change very quickly in DVB-H 
environments. 


PER 


Good metric to monitor and use for 

deciding when the signal quality is 

degrading. 

Provides good granularity on 

signal-quality conditions over time. 


Needs to demodulate a transport-stream. 
Needs to be measured over a period of 
time (e.g. 10 s). 


MFER 


May be a good metric to use for 
detecting an urgent need for handover. 
Provides good granularity on 
signal-quality conditions over time. 


Needs to demodulate a transport-stream. 
Needs to be measured over a period of 
time (e.g. 2 min). 

When problems are detected at the MFER 
level, it may be already too late to perform 
seamless handover. 



6.2.5.2 



Monitor existing signal quality 



When monitoring the signal-quaHty of a DVB-H signal, a combination of the SNR, PER and MFER metrics could 
provide good QoS information. 

In order to use the PER and MFER metrics, a pre-requisite is that the IP Flow(s) is successfully being consumed over a 
period of time (e.g. at least 10 s for PER; at least 2 min for MFER). 

Once the IP Flow(s) is stable, these metrics can be updated and monitored as time progresses. 

The PER metric can be used to give an indication of a slowly degrading QoS. 

It should be possible to set two threshold values: When the PER reaches the first threshold, this could trigger the 
receiver to start looking for a viable alternative signal, while still providing the service on the existing one (see 
figure 16, decision point A). 

If the second threshold value is reached, then handover to the best alternative signal should take effect (see figure 22, 
decision point B): note that this handover will only make sense if the "best alternative" signal is both available and 
quantifiably better than the current signal (see figure 22, decision points C and D). 

The SNR values can be compared and if there is a sufficient positive differential between the two values, then handover 
should take place (see figure 22, decision point D). 
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In addition to using the PER metric with two threshold values, the MFER metric can also be monitored. If the MFER is 
seen to change dramatically, then the signal quality could be considered to be degrading quickly: perhaps too quickly to 
wait for a second trigger value in order to seek handover to a better signal. 

In this case, the receiver should compare the existing SNR value to the SNR value of the "best alternative" signal, and if 
there is a sufficient positive differential between the two values, then handover should take place. 





Trigger evaluation 

of Alternative 

Signals 



Handover to the 
Best Alternative 





B 



Figure 22: Monitor existing signal quality 



6.2.5.3 



Evaluate alternative signal quality 



A pre-condition of this step, is that there is a list of possible alternative- signal candidates available. This pre-condition 
will be satisfied by following step 2 in clause 6.2.1. 

It is reasonable to assume that the off-time between bursts will be in the order of 2 s. The off-time may be much longer 
than this (i.e. 4 s or more [i.6]), but 2 s is a good rule-of-thumb to use for practical DVB-H network deployments. 
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Any measurements that need to take place during this evaluation cycle must take place in the off- time between bursts. 

The TPS carriers that are available in each DVB-H symbol carry information about the channel-coding, modulation and 
cell identification. These bits can be used during the quality assessment of the alternative frequencies. 

Evaluation of the alternative signals should be performed in a manner that is as time-efficient as possible. 

There are three possible metrics that could be used for this evaluation process, in a time-efficient manner: RSSI, DP 
and SNR. 

The SNR metric will provide the most useful information, and so it is the value that is recommended to be used if it is 
possible to do so. 

During the burst off-time, the receiver should cycle through the list of frequencies provided, and lock to each one. The 
TPS cell-id bits should be checked (to verify that this signal is indeed from the expected cell), and an SNR value should 
be estimated for each frequency. 

The frequency with the strongest SNR value should be considered the "best alternative" signal. 
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yes 



Figure 23: Monitor alternative signal quality 
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6.2.6 Handover execution 

After handover criteria have been met, the handover actually may be performed. Two algorithms for handover have 
been outlined in clause 5.1.1. The first one is based on the TPS and NIT and is limited to certain handover situations. 
This algorithm is described in detail in clause 6.2.6.1. The second algorithm, based on TPS, INT and NIT is suitable in 
all handover cases. It is described in clause 6.2.6.2. 
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Figure 24: Handover procedure 

In order to reduce the probability for data loss, the terminal should attempt to perform handover directly after a time 
slice was received from the currently consumed service from the current signal (see also TR 102 377 [i.3]). 



6.2.6.1 



Handover based on TPS and NIT 



This method assumes that handover conditions may exist to avoid INT parsing. This is true in the case of cell/sub cell 
ID and Network ID changes (Network ID change restricted to the condition: target NIT available, as shown in table 1), 
but the transport stream remains the same [i.3]. 
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Pre-conditions: 

1) Signal Scan / Initialization and bootstrap have already taken place. 

2) At least one good network signal carrying a TS has been identified, and this signal has been locked onto. 

3) There is relevant PSI/SI signalling available. 

4) A service is being provided. The service is described by: service_id; transport_stream_id; original_network_id, 
network_id. The IP Platform is described by: platform_id. 

5) At least one signal from a neighbouring cell is carrying exactly the same transport stream the receiver is 
currently consuming. 

Receiver Recommendations: 

1) The receiver must refresh its NIT_actual and NIT_other information every time a new multiplex is entered. 

2) If NIT_other is not available, the receiver may tune to other frequencies during the "off-cycle" of the burst, 
and derive NIT_other information by so-doing. 

NOTE: See clause 5 in TS 102 470-1 [4] for complete list of mandatory and optional signalling that needs to be 
provided by the network. 

3) TPS bits will always be transmitted on DVB-H networks. 

4) When TPS bits are transmitted, then the "cell_list descriptor" and the "cell_frequency_link descriptor" must be 
available in the NIT. This frequency list must be complete. 

6.2.6.2 Handover based on INT, TPS and NIT 

The limited handover TPS and NIT method described in clause 6.2.5.1 shall be replaced by the INT, TPS and NIT 
method when conditions defined in clause 6.2.5.1 are not met. This method should be used when a terminal sees that the 
original network ID and/or the transport stream ID changes as summarized in table 1 . The method relies on the fact that 
INT tables announce IP Flows of the same IP Platform on other networks. This method works with the same restricted 
conditions as clause 6.2.5.1 in the case of cell_id / subcell_id and network_id changes, i.e. INT tables shall announce IP 
Flows of the same IP Platform on other networks and target NIT is available. 

Pre conditions: 

1) Signal Scan / Initialization and bootstrap have already taken place. 

2) At least one good network signal carrying a TS has been identified, and this signal has been locked onto. 

3) There is relevant PSI/SI signalling available. 

4) A service is being provided. The service is described by: service_id; transport_stream_id; original_network_id, 
network_id. The IP Platform is described by: platform_id. 

5) At least one signal from a neighbouring cell is carrying exactly the same IP Flow the receiver is currently 
consuming. 

6) INT table announces all IP Streams on the actual TS; and it will also announce all relevant IP Streams on 
"neighbouring TSs". 

Receiver Recommendations: 

1) The receiver should refresh its INT information every time a new multiplex is entered. 
Network Recommendations: 

1) It is recommended that the INT is announced by adding a linkage_descriptor with linkage_type OxOB into the 
NIT on the actual TS. The list of announced INTs must be complete. 

2) If the NIT cannot be used for announcing INTs, then the linkage_type OxOC will announce the BAT on the TS. 
The BAT will contain linkage_type OxOB. 
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3) If a TS carries no INT (and therefore no IP Streams), the NIT on the particular TS should still announce INTs 
on other TSs of the actual network. 

NOTE: See clause 5 in TS 102 470-1 [4] for complete list of mandatory and optional signalling that needs to be 
provided by the network. 

1) Cell_id is mandatory for each cell where DVB-H services are delivered. The cell_id has to be announced in 
TPS bits as well as in the DVB SI. 

2) The NIT actual shall announce all multiplexes of the actual delivery system, and it shall contain one or more 
cell_list_descriptors announcing cells and sub-cells of the network. This list of cells and sub-cells shall be 
complete. 

3) To better support handover between networks, the presence of NIT_other for each adjacent network is 
proposed (and recommended). 

4) The receiver can achieve handover only if it knows the requested IP Flow is available on another multiplex 
and/or frequency: 

It is very important that a multiplex announces the content of adjacent multiplexes by means of INT 
announcing IP Flows on adjacent cells, that all frequencies of each multiplex are announced in the 
NIT_actual, and that the geographical locations of each cell is announced in the NIT_actual. 

5) If the INT does not indicate that a particular IP Flow is available on a particular TS, then the receiver may 
assume that it is not available on the TS. 

6.3 Roaming and special mobility cases implementation 
guidelines 

IPDC roaming is the procedure by which terminal finds an available ESG and a Roaming IPDC Operator that the 
terminal can access and consume IPDC services. 

The success to access services in the roaming situation depends on the up-to-date information about IPDC Operators 
available for roaming. That includes the information that is pre-provisioned in the terminal as well as the signalling 
provided to the terminal while roaming. 

A simple roaming strategy is to select the first IPDC Operator found and try to access services with "trial and error". 

A more optimised method to get an access to the services in a roaming situation, i.e. to find IPDC Operator(s) whose 
services terminal is able to access, is to efficiently utilize all the provisioned information for roaming. The following is 
a generic description of such a roaming procedure. Actual implementations of the generic procedure may vary. 
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Figure 25: Roaming Procedure 

For the broadcast network the procedure is: 

• Terminal initialize the roaming procedure by collecting terminal provisioned useful parameters. 

• The terminal accesses to the broadcast network, and collects the information of ESGs in all the IP Platforms, 
as well as local IPDC Operator and roaming IPDC Operator information that is signalled in the 
Roaminglnformation Descriptor. 

• The terminal categorizes roaming configurations. 

• The terminal/user select one of the IPDC Operators available, and consequently the ESG and the IP Platform 
which the selected IPDC Operator is present in: 

If the selected IPDC Operator is home IPDC Operator, the terminal may access the ESG and consume 
IPDC services in it. 

If the selected IPDC Operator is one of the roaming partner IPDC Operators, the terminal may access the 
ESG and consume IPDC services in it. 

If the selected IPDC Operator is an unknown IPDC Operator, terminal may access the ESG and try to 
consume IPDC services in it. If failed, terminal may select another unknown IPDC Operator and try 
again. 

Each of the above steps will be introduced in the following clauses. 
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6.3.1 Initialization 



Before IPDC roaming, the terminal may collect some information which may be useful to speed up the roaming 
procedure. The information includes: 

• Home IPDCOperatorld-IPDCKMSId pair, which SHOULD be provisioned to terminal, is the identifier of 
terminal's home IPDC Operator. 

• Compatible IPDCKMSId(s), which SHOULD be provisioned to terminal, is (are) the identifiers of the key 
management systems the terminal is able to deal with. 

• Home IP platform_id (and optionally the DVB Network_ID), which MAY be provisioned to terminal, is the 
identifier of IP Platform to which terminal should access to find its home IPDC Operator. When in the range 
between OxFFFOOO and OxFFFFFE, the IP platform_id should be coupled with DVB Network_ID to uniquely 
identify the IP Platform. 

• Home ProviderURI (ESG_URI in case of Phase II), which MAY be provisioned to terminal, is the identifier of 
the ESG that terminal may access to (by default). 

• Roaming IPDCOperatorld-IPDCKMSId pairs, which MAY be provisioned to terminal, are the identifiers of 
IPDC Operators that have IPDC roaming agreement with terminal's home IPDC Operator. 

6.3.2 Search all the available roaming configurations in Broadcast 
Network 

In order to find a proper Roaming configuration (i.e. IP Platform, ESG, IPDC Operator) in a broadcast network, the 
terminal may collect information about all the ESGs and IPDC Operators in all IP Platforms available in terminal's 
current location. It is done by receiving and analyzing ProviderDiscoveryDescriptors and Roaminglnformation 
Descriptor (if found) in every available ESG bootstrap. A detailed procedure is described below: 

• Step 1 : terminal receives all available INT sub-tables, each of which corresponds to an IP Platform. 



• 



• 



• 



Step 2: terminal selects an available IP Platform, and accesses to the ESG bootstrap on the IP Platform, as 
defined in [3]. 

Step 3: terminal receives and analyzes ESGProviderDiscovery Descriptor and Roaminglnformation Descriptor 
(if available), to collect all the potential roaming configurations on this IP Platform. 

Step 4: in case there is an IP Platform that have not been accessed, continue with step 2; otherwise end this 
procedure. 



At the end of the procedure, there will be a list of potential roaming configurations, each configuration in the list 
includes IP platform_id (possibly coupled with DVB Network_id), ESG_URI (ProviderURI in legacy cases) and the 
IPDCOperatorld-IPDCKMSId pair. 

6.3.3 Categorize and select Roaming Configurations 
6.3.3.1 Categorize Roaming Configurations 

After collecting all the roaming configurations, the terminal may categorize the parameters of each configuration: 

• IP Platform: it is identified as home IP Platform or visited IP Platform, by comparing the platform_id with 
Home IP platform_id. In the non-unique range, when between OxFFFOOO and OxFFFFFE, the platform_id 
should be coupled with the network_id. 

• ESG: it is identified as home ESG or visited ESG, by comparing the ESG_URI (ProviderURI in legacy cases) 
with home ESG_URI (ProviderURI in legacy cases). 
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• IPDC Operator: it is identified as Home IPDC Operator, Roaming IPDC Operator or Unknown IPDC 
Operator. A Roaming IPDC Operator may be identified by the fact that: 

The local IPDCOperatorld-IPDCKMSId pair obtained from the Roaminglnformation Descriptor is in the 
roaming IPDC Operator list provisioned in the terminal; or 

The home IPDCOperatorld-IPDCKMSId pair is signalled in the list of roaming partners of a Local IPDC 
Operator obtained from the Roaminglnformation Descriptor. 

6.3.3.2 Select a Roaming Configuration 

The terminal or user may select one of the roaming configurations according to its preference. It is done by: 
Step 1: Select an IPDC Operator 

• If the Home IPDC Operator or any of the Roaming IPDC Operators are present, the terminal or user may 
select one of them. 

• If not, the terminal may select one of the Unknown IPDC Operators available. Particularly, the terminal should 
select the IPDC Operator with a KMS system that the terminal can deal with. 

Step 2: Select an ESG 

• If several ESGs contain the selected IPDC Operator, the terminal may select one of them, for instance 
according to the signalling associated to the ESG entries in the ESGProviderDiscovery Descriptor. 

• Alternatively, the terminal may select an ESG carrying clear-to-air-services independent of the IPDC Operator 
based on the information available in the Roaminglnformation Descriptor. 

Based on the results of steps 1 and 2, the terminal is able to retrieve the corresponding IP Platform. 

6.3.3.3 Mapping to use cases 

The relationship between the different configurations and the mobility use cases described in clause 5.2 is as following. 
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Figure 26: Relation between potential roaming configurations and mobility use cases 
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6.3.4 Acquire roaming configurations via interactive network 

There are two possible mechanisms for acquiring roaming configurations via the interactive network. One is a generic 
IPDC mechanism described in [3]. The second option is to use a mechanism based on OMA DM where the terminal 
makes the roaming configuration selection according to an IPDC MO, which is acquired from the home DM server 
before roaming or is requested when roaming. The IPDC MO is described in [3]. 

6.3.5 Access an ESG 

After selecting one ESG, the terminal can access it as described in [3]. 

6.3.6 Validate an roaming configuration 

If the terminal selects one of the Unknown IPDC Operators, the terminal will need to validate the roaming 
configuration. After selecting an IPDC Operator and after accessing an ESG, the terminal may check whether this is a 
working roaming configuration. This check can be done by e.g. performing a purchase. 

NOTE: This process is time-consuming, therefore may gear down the roaming speed. 



Service Mapping 



A service could be identified by ServicelD which is assigned by one ESG provider (identified by ProviderURI). 
Services with same ServicelD but assigned by different ESG providers have no relationship. That means it could not be 
guaranteed whether two services with same ServicelD are the same service or not if their ServicelD is assigned by 
different ESG provider. 

Same or similar service could be existing in different networks. When the terminal needs to change to another reception 
for some reason, e.g. the current signal quality decreases, or the terminal changes the location, the terminal may want to 
continue the same or similar service as previous one from the new reception. If there is a different ESG provider in the 
new reception, the terminal should find the same or similar service in the another ESG provider. For supporting service 
continuity, ServiceMapping information is signalled in the service fragment in the ESG, to specify the same or similar 
service as the described service, but with different identifier (ServicelD) from other ESG provider and ESG. 

This service continuity mechanism is especially useful when the service on source cell is available identically or 
similarly on the target cell but carried by different IP flows and different Transport Stream, situation where normal 
handover procedure cannot detect an opportunity of service continuity. 

7.1 Scenario 

Figure 27 gives an example of Service mapping. There are two ESG providers, A and B, located in two networks. 
ESGProviderA provides Service 1, 2, and 3. ESGProviderB provides Service4, 5 and 6. Among them. Service 1 and 
Service4 are the same service, Service2 and Services have some variation, e.g. they use different languages. Services 
and Service6 are associated services. When the terminal moves from network of ESGProviderA to network of 
ESGProviderB, the terminal may continue rendering the same or similar service in the new network, based on service 
mapping information signalled in the ESG. 
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7.1.1 



Figure 27: Service Mapping example 



Service identifier mapping information 



In the example described in figure 27, Servicel from ESGProviderA and Service4 from ESGProviderB are the same 
services. 

The Service fragment in the ESG from ESGProviderB describes the information about Service4. Because Servicel from 
ESGProviderA is a same service as Service4, the 'MappingService' will list service identifier mapping information 
about Servicel. ESGProviderB is signalled in 'MappingProviderURI', the identifier for the ESG from ESGProviderB is 
signalled in 'MappingESGURI', and the Servicel is signalled in 'MappingServicelD'. 

Based on this, the terminal could get the identifier mapping information between Service4 and Servicel, as represented 
in table 4. 

Table 4: Service Identifier Mapping Information 





Service Identifier Mapping Information 


No. 


ESGProvider 


servicelD 


1 


ESGProviderB 


Service4 


ESGProviderA 


Servicel 
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7.1 .2 Service relationship indication 



As shown in example of figure 27, the relationship between two services could be various: 

• Identical service: Service 1 and Service4 are exactly the same. 

• Service with variation: Service2 and ServiceS may not be exactly the same but present some variation, e.g.: 

different language; 
different subtitle; 
different camera angle. 

• Associated service: Services and Service6 may be associated services, e.g. Services is CNN and Service6 is 
BBC, or weather forecast from different provider like CCTV weather forecast and Yahoo weather forecast. 

The 'ServiceRelationshipType' in the ESG service fragment will signal this information. 

Based on this, the terminal in the above example could construct this relationship information as represented by table 5. 

Table 5: ServiceRelationship 





ServiceldentifierMappinglnformation 


ServiceRelationship 


No. 


ESGProvider 


servicelD 




1 


ESGProviderB 


Service4 


Identical 


ESGProviderA 


Service 1 


2 


ESGProviderB 


Services 


Variation 


DifferentLanguage 


ESGProviderA 


Service2 


DifferentSubtitle 






DifferentCameraAngle 


3 


ESGProviderB 


Services 


Associated 


ESGProviderA 


Services 







7.2 Terminal procedure 

The terminal procedure is described in figure 28: 

1) The terminal selects an ESG Provider and a ESG. 

2) Whenever the user tunes to an IPDC service, the terminal checks for the presence of ServiceMapping 
information in the Service fragment associated to this IPDC service, and stores this ServiceMapping 
information along with ProviderURI and ESG_URI. 

3) Upon the event of user switching to another IPDC service. Step 2 is repeated. 

4) Upon the event (A) of decrease of signal quality, the terminal considers moving to another cell and inspects 
the availability of other Transport Streams on neighbouring cells, using PSI/SI and alternate signal reception: 

if the Service Mapping has been stored from current reception, the terminal tunes temporarily to the other 
Transport Stream, tunes to the ESG bootstrap FLUTE session, and acquires the ESGProviderDiscovery 
descriptor only. 

5) Upon the event (B) of moving to another cell (with no time to anticipate such move), the terminal tunes 
permanently to the other Transport Stream, tunes to the ESG bootstrap FLUTE session, and acquires the 
ESGProviderDiscovery descriptor. 
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6) If the Service Mapping has been stored from current reception, the terminal attempts to find in the 
ESGProviderDiscovery descriptor some ProviderURI and some pertaining ESG (ESG_URI) Hsted in the 
ServiceMapping information stored in previous reception. If a mapped ESG Provider and ESG_URI are found, 
and based on ServiceRelationshipType, the terminal could determine the nature of variation between the two 
services: 

if termID=1.0, it means an identical service exists in the current TS, announced by this ESG; 

if termID=2.x, it means a similar service with some variation exists in the current TS, announced by this 
ESG: 

■ termID=2.1, means service with different language; 

■ termID=2.2, means service with different subtitle; 

■ termID=2.1, means service with different camera angle; 

if termID=3.0, it means an associated service exists in the current TS, announced by this ESG. 

7) If no mapped service is found, or if some is found but with a variation which is not acceptable: 

In case of event (A), the terminal attempts the same procedure with some other neighbouring TS; 
In case of event (B), the terminal applies some other procedure of ESG Provider and ESG selection. 

8) The terminal then acquires the selected ESG, retrieves the Service fragment for which the service mapping is 
defined (i.e. containing a ServiceMapping information with MappingServicelD, MappingProviderURI, and 
MappingESGURI matching the service monitored on previous cell), and tunes to this service. 
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Figure 28: Terminal procedure for ServiceMapping handling 
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Annex A (normative): 

ESG bootstrap extension for mobility support 



A.1 Introduction 



The Roaminglnformation Descriptor that will be defined in the following provides quickly accessible information in the 
ESG bootstrap so that a terminal is able to quickly obtain information of which Local IPDC Operators are present on a 
certain ESG, which roaming partners the Local IPDC Operators have and whether clear- to-air services are present in 
that ESG. 

The Roaminglnformation Descriptor is optional for the network infrastructure and the terminal. However, if used, it 
shall follow the specifications in this annex. 

If the Roaminglnformation Descriptor is used, the Local IPDC Operators and the availability of clear-to-air services 
shall be signalled. However, signalling of roaming partners (i.e. the second loop of the descriptor) is optional. 



A.2 Roaminglnformation Descriptor 



A.2.1 Syntax 



Table A.1 : Syntax of the Roaminglnformation Descriptor 



Syntax 


No. Of 
bits 


IVInemonic 


Roaminglnformation Descriptor{ 






Version no 


8 


Uimsbf 


Descriptor_tag 


8 


uimsbf 


n_o_Operators 


8 


uimsbf 


for(i = 0; i<n o Operators; i + + ) { 






Operator_Index [i] 


8 


uimsbf 


IPDC_Operator_ID [i] 


16 


uimsbf 


KMS ID[i] 


16 


uimsbf 


} 






n o local Operators with signaled Roaming Partners 


8 


uimsbf 


for(i=0; i<n_o_local_Operators_with_signaled_Roaming_Partners; i++) { 






Local Operator with signaled Roaming Partners Index [i] 


8 


uimsbf 


N_o_Roaming_Partners_signaled [i] 


8 


uimsbf 


for(k=0; k<n o Roaming Partners signaled[i]; k++) { 






Signaled Roaming Partner Index [i] [k] 


8 


uimsbf 


} 






} 






n_o_ESG_IDs 


8 


uimsbf 


for(i=0; i< n o ESG IDs; i++){ 






ESG_ID[i] 


16 


uimsbf 


Clear- to- air_services_available [i] 


8 


uimsbf 


N_o_local_Operators_on_ESG [i] 


8 


uimsbf 


for(k=0; k< n_o_local_Operators_on_ESG [i] ; k++) { 






local Operator on ESG Index [i] [k] 


8 


uimsbf 


} 






} 






} 
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A.2.2 Semantics 



Table A.2: Semantics of the Roaminglnformation Descriptor 



Field 


Semantics 


Version_no 


Specifies the version of roaming information 
descriptor. The value shall be 1 . 


Descriptor tag 


Identifies uniquely the descriptor. 


n_o_Operators 


Specifies the number of the IPDC Operators used 
in the following loop. 


Operator_lndex 


Specifies the index for the i_th IPDC Operator used 
for referencing in the lower part of the descriptor. 


IPDC_Operator_ID 


Specifies the IPDCOperatorld for the i_th IPDC 
Operator. 


KMS ID 


Specifies the IPDCKMSId for i_th IPDC Operator. 


n_o_local_Operators_with_signaled_Roaming_Partners 


Specifies the number of the local IPDC Operators 
for which roaming partners are signalled. In the 
case that roaming partners are signalled for none of 
the local IPDC Operators, the parameter should be 
set to 0. 


local_Operator_with_signaled_Roaming_Partners_lndex 


Specifies the index of the i_th local IPDC Operator 
with signalled roaming partners. 


n_o_Roaming_Partners_signaled 


Specifies the number of roaming partners signalled 
for the i_th local IPDC Operator with roaming 
partners. 


Signaled_Roaming_Partner_lndex 


Specifies the index of the k_th roaming partner of 
the i th local IPDC Operator with roaming partners. 


n ESG IDs 


Specifies the number of ESGs. 


ESG ID 


Specifies ESGID for the i th ESG. 


clear-to-air_services_available 


(MSB first): 

bOxxxxxxx: no CTA 

b10000000:CTA available 

b1yyyy777: yyyy CTA services which are 

permanently available (if yyyy=1 111 it would mean 

15 or more); 777 services available CTA only 

part-time (if zzz=1 1 1 it would mean 7 or more). 


n_o_local_Operators_on_ESG 


Specifies the number of local IPDC Operators in 
the i th ESG. 


local_Operator_on_ESG_lndex 


Specifies the index of the k_th local IPDC Operator 
on the i th ESG. 



A.2.3 Transport 



The Roaminglnformation Descriptor is transported in the ESG Bootstrap FLUTE session in a well-known IP address 
and port, as defined in [3]. 

Additionally the following restrictions apply: 

• The Roaminglnformation Descriptor is transported in a dedicated transport object in the bootstrap FLUTE 
session. It should be signalled in the FDT by setting the attribute. 

• Content-Type="application/vnd.dvb.ipdcroaming" . 
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